如果還沒有看上一篇的讀者，歡迎先看看我們在使用 BigQuery procedure 來做資料轉換遇到了什麼痛點，本篇會針對上一篇的幾個痛點一一做討論～

一、Procedures 的管理不易

過於扁平的資料集架構增加了 procedures 的管理難度，dbt 在手冊中指引我們新的架構，首先從資料的上游至下游，將轉換分為幾個階段：staging, intermediate, mart 三個層級，有點類似另外一種將資料庫分成金銀銅等級來辨別資料乾淨程度的概念。

由上游至下游分別介紹：

• staging: 僅針對原始資料做簡單的型別轉換、時區轉換或統一命名規則等。在這個層級中，依照資料的來源再去做平行的區分，像是我們平台就會分成平台備份資料、GA 紀錄資料、即時串流資料、公開資料、以及 GCP 運算的 metadata，如帳單、運算詳細紀錄等。
• intermediate: 進行複雜的轉換與聚合等等，在這個層級的重點是重用性，可能很多業務單位都有類似的需求，在這個層級做好轉換，讓下游的資料表可以不用各自重工做一樣的處理。
• mart: 即為大家認識的 data mart。在這邊比較有趣的一點是，在這個層級中，我們按照業務邏輯來做分類，不同業務面有不同的好奇、定義，在這個層級中就可以清楚地呈現。

雖然 dbt 是透過 BigQuery 的 API 運算，最終資料表仍然是在 BigQuery 的資料集中呈現，一樣是扁平的資料架構，然而重點在於工程開發時，資料表是被良好分類收納做管理的，在開發 pipeline 時十分順手。

真的沒辦法用 BigQuery 來解決這個問題嗎？

procedures 亂成一團是我們一開始深受困擾的問題，我們當然也想了很多方法來解決。其實也可以直接將這套原則挪用到 BigQuery 中，只是架構扁平，可能會是用 staging_ga, staging_platform, staging_streaming 這樣的資料集來做管理，雖然有點阿雜，但 hmm…，沒有不行。

二、版本控制不易徹底落實

dbt 可以直接設置專案 repo，便利地在 vscode 等編譯器上做開發跟測試，即可同步進行版本控制，這邊後續會再做不少討論，包含 dbt core 如何設置，如何讓所有的工程師與分析師快速部署環境進行開發等等。

真的沒辦法用 BigQuery 來解決這個問題嗎？

其實也可以直接在 vscode 設定憑證，執行 procedure，這樣編輯完後就可以直接發 PR 同步進行版本控制，但 procedure 包含 DDL(CREATE, ALTER…) 語言，在開發測試時需要預覽資料時，就要將其註解掉，而正式使用時又需要撤銷註解，這種要因應環境不同必須反覆操作的行為，很容易在開發時出現失誤，應該盡可能避免。

再加上 procedure 沒有像 dbt 有 power user 這麼強力的套件，可以預覽、驗證正確性、估計運算量、看資料血緣、編輯文件跟測試，近期甚至還可以導入 DataPilot 可以一鍵解析程式碼，我得說 dbt 可以大幅度優化開發體驗，power user 絕對是主要功臣。

三、執行不易模組化

回頭看來，目前我們使用 dbt 是用 daily, weekly, monthly 等標籤來管理相關的 models 做相對應的 pipeline 的觸發（官方文件），這個標籤的設置讓我只需要在 data mart 中的資料表做設定即可，因為 dbt 可以自動判讀資料表間的血緣關係，可以連同其上下游一起進行更新（官方文件），業務單位希望哪一張表的更新週期要改變，我只要改那一張表，並用 + 來一併更新其上游即可。

而與 airflow 的互動方式是，它會依照標籤去觸發相對應的 pipeline。這樣做的好處是，在我需要從周更改日更時，我只需要在 dbt 的 repo 中調整標籤，完全不需要動到 airflow repo 中的程式碼，將這兩個部分完全獨立開來！

真的沒辦法用 BigQuery 來解決這個問題嗎？

我們有嘗試在原先使用 BigQuery procedure 的情況下，在 airflow 進行不同區塊的模組化，讓我們在 airflow repo 中比較好去釐清資料表間的關係，然而光是把 procedure 跟 airflow 的邏輯嘎在一起，就蠻令人煩躁的了。

四、不易記錄資料的 metadata

dbt 用 yml file 來管理資料表的文件，讓我們在開發時一目了然。並且還可以在 yml 中放入預設的測試，最常使用的包含： not null, unique, accept value 等等，也有很多擴充套件來讓你的測試更加適配於你的資料。

關於文件與測試的一些用法跟注意事項，後續會再補充。

真的沒辦法用 BigQuery 來解決這個問題嗎？

BigQuery 雖然也可以寫文件，他有提供資料表標籤、可以在程式碼的 OPTION 中編寫資料表及欄位的說明，但實在不是太好用，無法一目了然。最大的問題是，BigQuery 沒有辦法快速實現測試功能，需要自己手刻相關的檢查工具，來驗證資料的正確性。

這兩篇或許有些先射箭後畫靶的意味在，不過從結果看來，現在回想起來，這些仍然是我們當時遇到最主要的問題，也確實是 dbt 幫助我們優化的環節。

當然不排除有些 dbt 也沒有辦法很好解決的痛點我忽略掉了ＸＤＤＤ，但無法否認上述列下的幾點，我是覺得蠻值得的。